home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Mar 91 / MacApp.Tech$ 3⁄8⁄91 / 3170-Another MA3 opinion -Mar91 < prev    next >
Encoding:
Text File  |  1991-04-01  |  3.3 KB  |  63 lines  |  [TEXT/GEOL]
  1. Item    7252095                         4-March-91        10:59PST
  2.  
  3. From:   ALGER                           Alger, Jeff,VCA
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    Another MA3 opinion (long)
  10.  
  11. James, Lee, Joe,
  12.  
  13. James, you have a knack for asking the "dumb" question that leaves everyone
  14. else scrambling to avoid looking dumb in responding.  I agree, it's a pretty
  15. damning statement to say that the Toolbox is more stable and easier to change
  16. than object-oriented code in general and MacApp in particular.  Let's not deny
  17. the discomfort, but deal with it constructively.
  18.  
  19. There is one obvious explanation for this and one not-so-obvious.  The obvious
  20. one, particularly in the MacApp community, is that people take on more
  21. ambitious projects when armed with MacApp-caliber class libraries.  This
  22. ambition, in itself, leads to bigger maintenance problems than for simpler
  23. projects.
  24.  
  25. The more subtle problem strikes at the heart of object-oriented software
  26. engineering.  I recall reading something by Dijkstra back in ancient times
  27. damning the GOTO statement in simple terms: if GOTOs are allowed in a program,
  28. you cannot tell by looking at a line of code how you got there.  Not that
  29. GOTO-less programs are perfect in this regard, just better, since sequence (one
  30. line following another), iteration and selection (IF-THEN) were the only
  31. control structures.  Enter inheritance and polymorphism, the modern equivalent,
  32. in software engineering terms, of the GOTO.  When designing a method, you
  33. cannot tell whether it will be reached from within the same class, by
  34. inheritance from a subclass, through a call to INHERITED, or not at all due to
  35. either a complete override of that method or an override of some other method
  36. that would otherwise call it.  You also cannot tell from looking at a method
  37. what else it will call when invoked, again because of the possibility of
  38. overrides of both that method and the receiving end of the calls.  No wonder it
  39. takes a couple of years to get the hang of OOP!
  40.  
  41. One good technique for overcoming this problem is to design the run-time
  42. environment first, in which inheritance and polymorphism and, yes, even the
  43. class library, have been factored out and all that you have are objects, each
  44. of which has a fixed-for-all-time set of methods with specific implementations.
  45. Once that architecture is in place, one can create an optimal implementation
  46. using inheritance and polymorphism in the language (i.e., pre-compilation)
  47. model and borrow from the class library where appropriate.  Another technique
  48. (implicit in the nested, inherited structure of Eiffel pre- and
  49. post-conditions, by the way) is to never completely override the behavior of a
  50. method and always call the INHERITED version at some point.  Neal Goldstein has
  51. coined the term "normal" inheritance for this.  "Never" is, of course, an ideal
  52. not always achievable, but it is amazing how differently one designs class
  53. hierarchies with this in mind.  What this guarantees is that a client can
  54. always count on a certain basic behavior; the subclass merely enhances the
  55. behavior.  It also leads to the phenomenon you describe, Lee, of being able to
  56. achieve wide-ranging constructive change with little effort.
  57.  
  58. This link is already too long, so I'll stop here.  Comments, anyone?
  59.  
  60. Regards,
  61. Jeff Alger
  62.  
  63.